Known barcode readers include firmware stored in non-volatile memory which, upon power-up is loaded to volatile memory (RAM) as executable code. A processor executes the executable code from RAM for operating the barcode reader. The firmware may include an operating system (e.g., Linux®), drivers for the hardware components such as the image sensor array and communication hardware, a decoder, and formatting/routing instructions (i.e., instructions for parsing, formatting, and routing decoded data) (collectively, referred to as operating instructions).
In a first known configuration, the firmware stored in non-volatile memory includes the components of the operating instructions, at least some of which include position independent code. In this configuration each component of the firmware may be loaded to RAM at address space determined by a hardware or software virtual memory manager such that, once loaded to RAM, the instructions can be executed by a processor in combination with the hardware or software memory manager.
In a second known configuration, the firmware stored in the non-volatile memory may include a RAM image. The RAM image includes all portions of the operating instructions compiled as a unified block of machine code instructions which is loaded within predetermined physical address space such that internal address links align with physical address locations within the RAM and the unified block of machine code instructions may be executed without use of a memory manager for address translation.
In either known configuration, part of the firmware may include a remote upgrade system. The remote upgrade system may be part of the executable code and it enables upgrade of the firmware.
In more detail, known remote upgrade systems will obtain an upgrade file and store the upgrade file in storage. In the first configuration the upgrade file may be a .zip or similar file which includes multiple files which are intended to replace the multiple files of the then existing firmware. In this configuration the upgrade system writes each new file to non-volatile memory in replacement of an existing file.
In the second configuration the upgrade file may simply be a binary object which is intended to replace the unified block of machine code instructions. In this configuration the upgrade system writes the binary object to non-volatile memory in replacement of the existing unified block of machine code instructions.
In either configuration, when writing the new file(s) to non-volatile memory is complete, the unit undergoes a re-boot which loads the new file(s) from non-volatile memory to the RAM for execution—with the effect being that the new file(s) replace the old files within the RAM.
There are at least two problems with these known configurations. First, flash memory is expensive and writing to flash memory is slow. Second, updating any of the firmware, decoder, formatting/routing instructions, and other executable code requires re-flashing the reader. This can be a logistical problem in an environment with many readers that should have the same version of the firmware, decoder, formatting/routing instructions, etc.